Decentralized system for performing blockchain-based token management using a side-blockchain network

ABSTRACT

A decentralized system is provided for using smart contracts executed on a side-blockchain network for performing token management by limiting token withdrawals from restricted wallets until an owner of the restricted wallet has met specified criteria and by permitting recapture of tokens from restricted wallets when the owner of the restricted wallet fails to meet the specified criteria within a specified time limit.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.17/520,788, filed Nov. 8, 2021, entitled “DECENTRALIZED SYSTEM FORPERFORMING BLOCKCHAIN-BASED TOKEN MANAGEMENT USING A SIDE-BLOCKCHAINNETWORK”, which is hereby incorporated herein by reference in itsentirety.

TECHNICAL FIELD

The present disclosure relates generally to decentralized systems andmore particularly to performing blockchain-based token management.

SUMMARY

Transaction fees on main blockchain networks (e.g., the Ethereum mainnetwork) have risen to rates that are far too expensive fordecentralized applications (DApps) to run efficiently, and transactionsper second (tps) are still well behind comparable centralized systems.This has created an issue for running electronic games on blockchainnetworks.

In different countries, the legality of electronic games depends onwhether the electronic games are being played for money. This differenceresults in two different classes of players: real money players and fakemoney players. It is not currently possible for games played ondecentralized systems to allow real money players and fake money playersto play electronic games together.

The present disclosure provides a decentralized system using smartcontracts executed on a side-blockchain network for performing tokenmanagement by limiting token withdrawals from restricted wallets untilan owner of the restricted wallet has met specified criteria and bypermitting recapture of tokens from restricted wallets when the owner ofthe restricted wallet fails to meet the specified criteria within aspecified time limit.

While several features are described herein with respect to embodimentsof the invention; features described with respect to a given embodimentalso may be employed in connection with other embodiments. The followingdescription and the annexed drawings set forth certain illustrativeembodiments of the invention. These embodiments are indicative, however,of but a few of the various ways in which the principles of theinvention may be employed. Other objects, advantages, and novel featuresaccording to aspects of the invention will become apparent from thefollowing detailed description when considered in conjunction with thedrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

The annexed drawings, which are not necessarily to scale, show variousaspects of the invention in which similar reference numerals are used toindicate the same or similar parts in the various views.

FIG. 1 is a schematic diagram of an embodiment of a decentralized systemfor performing blockchain-based token management.

FIG. 2 is an exemplary ladder diagram showing a depositing event and awithdrawal event.

FIG. 3 is a schematic diagram of a bridge smart contract.

FIG. 4 is a schematic diagram showing exemplary specified criteria.

FIG. 5 is an exemplary ladder diagram showing transfer of assets betweena primary chain wallet and a sidechain user wallet.

FIG. 6 is a schematic diagram of deposit data.

FIG. 7 is a schematic diagram of withdrawal data.

FIG. 8 is a schematic diagram of a node.

FIG. 9 is a schematic diagram showing interaction of smart contracts ofthe side-blockchain network.

FIG. 10 is a flow diagram of an embodiment of a method forblockchain-based token management using a side blockchain connected to aprimary blockchain by a bridge

The present invention is described below in detail with reference to thedrawings. In the drawings, each element with a reference number issimilar to other elements with the same reference number independent ofany letter designation following the reference number. In the text, areference number with a specific letter designation following thereference number refers to the specific element with the number andletter designation and a reference number without a specific letterdesignation refers to all elements with the same reference numberindependent of any letter designation following the reference number inthe drawings.

DETAILED DESCRIPTION

According to a general embodiment, a decentralized system is providedfor performing token management by using smart contracts executed on aside-blockchain network. The smart contracts limit token withdrawalsfrom restricted wallets of the side-blockchain network until an owner ofthe restricted wallet has met specified criteria. The smart contractsalso permit recapture of tokens from restricted wallets when the ownerof the restricted wallet has not met specified criteria within a timelimit.

Turning to FIG. 1 , an exemplary embodiment is shown of a decentralizedsystem 10 for performing blockchain-based token management using aside-blockchain network 12. the decentralized system 10 includes aside-blockchain network 12 in communication with a plurality of userdevices 16, and a cross-chain bridge (also referred to as a bridge) 18.The side-blockchain network 12 includes a plurality of nodes 14 and atrust entity 20. The cross-chain bridge 18 is in data communication withthe side-blockchain network 12 and a main-blockchain network 24 fortransferring digital assets 26 between the side-blockchain network 12and the main-blockchain network 24 by executing a bridge smart contract28.

The decentralized system 10 may use the main-blockchain network 24(e.g., the Ethereum blockchain) to manage all funds transfers (e.g.,deposits and payouts). Because transaction fees and performance may beissued on the main-blockchain network 24, the decentralized system 10moves higher-frequency, lower-value in-game transactions to theside-blockchain network 12 (e.g., a private blockchain). Theside-blockchain network 12 communicates with the main-blockchain network24 via the bridge 18.

With exemplary reference to FIG. 2 , the transfer of the digital assets26 by the cross-chain bridge 18 includes both depositing events 30 andwithdrawal events 32. A depositing event 30 transfers assets 26 from aprimary chain wallet 34 to a sidechain user wallet 36. Conversely, awithdrawal event 32 transfers assets 26 from a sidechain user wallet 36to a primary chain wallet 34.

Turning with exemplary reference to FIG. 3 , at least two requiredsignatures 38 are required for the bridge smart contract 28 to perform awithdrawal event 32: a signature of an owner 42 of the identifiedsidechain user wallet 36 and a signature of the trust entity 44. Theowner may sign 42 the bridge smart contract 28 for the withdrawal event32 when requesting the withdrawal. For example, the owner may sign thebridge smart contract 28 by sending a transaction to configure thebridge smart contract 28.

When a smart contract is described herein as being modified in some way(e.g., being signed, initiating, etc.), this modification may beperformed by a computing device (e.g., the trust entity 20, a node 14,bridge node 120, user device 16, etc.) sending a transaction to thesmart contract (e.g., on the side-blockchain network 12) to perform themodification.

The trust entity 20 signs a bridge smart contract 28 for a withdrawalevent 32 (1) when the sidechain user wallet 36 is an unrestricted walletor (2) when the sidechain user wallet 36 is a restricted wallet and theaccount associated with the sidechain user wallet 36 has met specifiedcriteria 50. Conversely, the trust entity 20 does not sign a bridgesmart contract 28 for a withdrawal event 32 when the sidechain userwallet 36 is a restricted wallet and the account associated with thesidechain user wallet 36 has not met the specified criteria 50.

In one embodiment, the trust entity 20 signs the bridge smart contract28 by sending a transaction to configure the bridge smart contract 28when an account has met the specified criteria 50. That is, instead ofwaiting for a withdrawal 32 or depositing event 30 and then signing thebridge smart contract 28 (e.g., by sending a transaction to configurethe bridge smart contract 28 to approve the withdrawal 32 or depositingevent 30), the trust entity 20 instead signs the bridge smart contract28 when an account meets the specified criteria 50. In this way, thetrust entity 20 may be considered to have signed or not signed an event30, 32 before the event 30, 32 has been requested. In one example, thetrust entity 20 continuously maintains a state of the bridge smartcontract 28 by monitoring for when accounts meet the specified criteria50 and updating the bridge smart contract 28 accordingly.

As described above, a trust entity 20 may be required to sign a bridgesmart contract 28 for a withdrawal event 32 to be performed and a trustentity determines whether an account associated with a sidechain userwallet 36 has met specified criteria before signing a withdrawal event32.

When the bridge smart contract 28 for a deposit event 30 has receivedthe two required signatures 38, the bridge smart contract 28 may beexecuted by the bridge nodes 120, such that the withdrawal event isperformed.

In one embodiment, limiting players from withdrawing funds untilspecified criteria are met allows for the side-blockchain network 12 tohave real money players play electronic games against players that didnot provide their own funds, but rather received funds from anothersource (e.g., also referred to as play to earn players). For example, inthe US where playing poker online for real money is currently illegal,it may be legal for US players to play against real money players usingfunds (i.e., tokens, digital assets, etc.) provided as part of apromotion (e.g., the player only gets to keep the funds if the playermeets the specified criteria).

In the embodiment depicted in FIG. 4 , the specified criteria 50identifies at least one action 52 that the account associated with thesidechain user wallet 36 is required to take within a time limit 54. Forexample, the specified criteria 50 may specify that an account must playone thousand (1,000) hands of a card game to withdraw sidechain digitaltokens 56 from their sidechain user wallet 36. In this example, thesidechain digital tokens 56 may have been given to the owner 58 of theaccount as part of a promotional event. In the promotional event,players may be given an amount of sidechain digital tokens 56 to playwith. Players may only withdraw these tokens if they have played anidentified number of hands within a time limit 54. If the players meetthe specified criteria 50, then the players may be able to withdraw anyremaining sidechain digital tokens 56.

In addition to signing bridge smart contracts 28, the trust entity 20also executes identity smart contracts 62. In one embodiment, theidentity smart contract has two main purposes: holding user funds; andcreating permissioned access to the side-blockchain network 12. Theidentity smart contract 62 may also allow the users to request the trustentity 20 to update their game play wallet (e.g., in case of a computercrash and the game play wallet is missing). The identity smart contract62 may approves by ins and may allow for ownership of a user's wallet tobe transferred.

In addition to limiting player withdrawals using the trust entity 20(e.g., allowing the side-blockchain network to prevent transfer of fundsout of the side-blockchain network until the specified criteria 50 havebeen met), the identity smart contract 62 allows the trust entity 20 torecover digital assets 26. In one embodiment, the identity smartcontract 62 controls access to the sidechain user wallets 36 by removingthe digital assets 26 from each of the restricted wallets 48 when theaccount 52 associated with the sidechain user wallet 36 has not met thespecified criteria 50. In the above example, if a player does not playthe required 1,000 hands within 30 days, then the digital assets 26supplied to the player may be removed from the player's sidechain userwallet 36.

In one embodiment, the bridge 18 has two core functions: (1) to relaytransactions between the main-blockchain network 24 and theside-blockchain network 12, and (2) to secure the funds transferred fromthe main-blockchain network 24 to the side-blockchain network 12. Thebridge may also be used to limit withdrawal events 32 and deposit events30. For example, withdrawal requests for individual players may beblocked if the player is suspected of cheating, money laundering, etc.The bridge 18 may also be used to set deposit limits, and even blockdeposit attempts from unverified users.

As described above and with exemplary reference to FIG. 5 , in responseto being executed, the bridge smart contract 28 transfers digital assets26 between one or more primary chain wallets 34 and the sidechain userwallets 36. The transfer of the digital assets 26 includes bothdepositing events 30 and withdrawal events 32. The depositing events 30include receiving deposit data 100 from the cross-chain bridge 18 andtransferring a corresponding deposit amount of a sidechain digital token102 to one or more sidechain user wallets 36. In the exemplaryembodiment shown in FIG. 6 , the deposit data 100 includes a depositingamount of a primary chain digital token 104 and an identifier of atleast one primary chain user wallet 144. One or more sidechain userwallets associated with the identified at least one primary chain userwallet 114 may be determined by the system 10. For example, thesidechain bridge smart contracts may map (i.e., associate) primary chainuser wallet(s) to sidechain user wallet(s). As another example, thetrust entity 20 may use a lookup table to determine the at least onesidechain user wallet associated with identified at least one primarychain user wallet 114. Alternatively, the deposit data 100 may includingan identifier for at least one sidechain user wallet. The correspondingdeposit amount of the sidechain digital token 108 corresponds to thedepositing amount of the primary chain digital token 104.

The withdrawal events 32 include receiving withdrawal data 110 andtransferring a corresponding withdrawing amount 112 of the primary chaindigital token 104 to the identified at least one of the primary chainwallets 34 from the at least one sidechain user wallet 36 associatedwith the identified at least one of the primary chain wallets 34. In theexemplary embodiment shown in FIG. 7 , the withdrawal data 110 includesa withdrawing amount 112 of the sidechain digital token 56 and anidentifier of at least one primary chain wallet 114. The correspondingwithdrawing amount of the primary chain digital token 116 corresponds tothe withdrawing amount 112 of the sidechain digital token 56.

As described above, the side-blockchain network 12 is a separateblockchain that is attached to the main-blockchain network 24 using abridge 18. For example, the side-blockchain network 12 may be anyprogrammable blockchain usable by an application to handlehigher-frequency lower-value transactions that would be expensive toprocess on the main-blockchain network (e.g., Ethereum mainnet) and thatcan be customized to suit the business needs of a decentralizedapplication (DApp). In one embodiment, the side-blockchain network 12 isa private blockchain. As a private blockchain, certain data may be keptprivate by the side-blockchain network. For example, the results ofelectronic games may be kept private.

The side-blockchain network 12 may be aligned in parallel with themain-blockchain network 24 and the bridge 18 allows for the digitalassets 26 to move between the side-blockchain network 12 andmain-blockchain network 24 and to be used across the side-blockchainnetwork 12 and main-blockchain network 24. For example, the bridge 18may act as a relayer (i.e., allowing assets 26 to move between the twochains) and as a gatekeeper (i.e., used to ensure transactions betweenthe side-blockchain network 12 and main-blockchain network 24 areconducted in a secure manner). In one embodiment, the side-blockchainnetwork is built on top of Kaleido (an AWS Market Application thatprovides Blockchain as a Service (BaaS)).

In the embodiment shown in FIG. 8 , each node 14 of the side-blockchainnetwork 12 includes a computer processor 80 and a non-transitorycomputer-readable storage medium 82 including a plurality of executableinstructions 84. In response to executing the plurality of executableinstructions 84, the computer processor 80 of each node 14 is configuredto execute sidechain smart contracts 64 and a copy of a blockchain 66 ofthe side-blockchain network 12. The blockchain of the side-blockchainnetwork includes game wallets 72. The sidechain smart contracts 64include a table factory smart contract 68 and table smart contracts 70.

As is described in further detail below, the decentralized system 10 maybe utilized for performing electronic games 95 and electronic gamingevents 96. A table smart contract 70 may represent a single instance ofa game (e.g., a poker table where multiple hands of poker will beplayed). That is each game (e.g., each poker table) on theside-blockchain network 12 may be represented by a new table smartcontract 70.

In the embodiment shown in FIG. 9 , the table factory smart contract 68deploys the table smart contracts 70. When the table factory smartcontract 68 creates a table smart contract 70, the table smart contract70 may be configured with the desired parameters for the electronic game95 represented by the table smart contract 70. The desired parametersmay be passed by an operator to the table factory smart contract 68along with the request for creating the table smart contract 70.

In one embodiment, the table smart contracts 70 represent each one ofthe tables available for play. The table smart contract 70 may keeptrack of the players 88 that are seated and their stakes. The tablesmart contracts 70 may receive the hand reports generated at the end ofeach hand to update the stakes of each player 88 (e.g., as is describedin further detail below, validating the signatures of the players 88).

In one embodiment, the table smart contracts 70 controls players 88joining an electronic game 95 by receiving buy-ins from players 88. Thatis, each of the table smart contracts 70 may be associated with a tablewallet 86 comprising at least one of the game wallets. Each of the tablesmart contracts 70 join at least one of the accounts 49 as a player 88of the table smart contract 70 by transferring digital assets 26 fromthe sidechain user wallet 36 of the player 88 to a table wallet 86associated with the table smart contract 70. The transferred digitalassets 26 may be stored in the table wallet 86; such that the digitalassets 26 are associated with the transferring player 88. An electronicgame event 96 may begin when one or more players 88 have joined theelectronic game 95 via the associated table contract 70.

During gameplay (i.e., during an electronic gaming event 96), allblockchain transactions may occur in the side-blockchain network 12. Asdescribed above, this removes transaction costs for the player 88compared to if the transactions were occurring on the main-blockchainnetwork 24, where transactions costs (e.g., Ethereum gas) may berequired for every transaction to occur on the main-blockchain network24.

In one embodiment, the table smart contract 70 includes the gameparameters: e.g., buy-in amount, game type, payout structure, number ofplayers, etc. The table smart contract 70 may include a chip counter tokeeps track of players' stakes at each table.

Each of the table smart contracts 70 also track as available funds thedigital assets 26 stored in the table wallet 86 for each of the players88. This tracking of available funds includes receiving results 94 of anexecuted electronic game event 96 associated with the table smartcontract 70. The results 94 include a funds update 98 identifyingchanges in the available funds for at least one of the players 88. Thistracking of funds may also include paying players 88 out as they exitthe game by crediting the player's sidechain user wallet 36 with theappropriate amount based on the game outcome. For example, each of thetable smart contracts 70 may remove at least one of the players 88 fromthe table smart contract 70 by transferring the available funds from thetable wallet 86 for the player to the sidechain user wallet 36 of theplayer 88.

Each user device 16 has an account associated with a sidechain userwallet 36. In one embodiment, each of the side chain user wallets 36(i.e., each sidechain user wallet associated with a user device 16) iseither a restricted wallet or an unrestricted user wallet.

Each user device 16 also includes a computer processor 80 and anon-transitory computer-readable storage medium 82 including a pluralityof executable instructions 84 executable by the computer processor 80.

In addition to players 88, the table smart contract 70 may also identifyjustices 89. The justices 89 may be non-players used to ensure that theresults of the electronic game events 96 are accurately reported to thetable smart contract 70. The justices perform justice services byobserving the electronic gaming event 96, and before the result of theelectronic game event is reported to the table smart contract 70, thejustice 89 digitally signs the result of the electronic game event 96.The table smart contracts 70 may identify the justices 89 that arepermitted to perform justice services at the table.

The plurality of justices 89 each including a computer processor 80, anon-transitory computer-readable storage medium 82 including a pluralityof executable instructions 84.

The trust entity 20 (also referred to as an application backend) is oneor more computing device(s) including a computer processor 80 and anon-transitory computer-readable storage medium 82 including a pluralityof executable instructions 84. In response to executing the plurality ofexecutable instructions 84, the computer processor 80 of the trustentity 20 is configured to sign a bridge smart contract 28 and toexecute an identity smart contract 62. For example, the trust entity 20may be a server or cluster of servers.

The cross-chain bridge 18 includes one or more bridge nodes 120. Eachbridge node 120 includes a computer processor 80 and a non-transitorycomputer-readable storage medium 82 including a plurality of executableinstructions 84. As described above, in response to executing theplurality of executable instructions 84, the computer processor 80 ofeach bridge node 120 is configured to execute a bridge smart contract28.

The bridge 18 may be managed by a set of bridge nodes 120 acting asvalidators. The bridge nodes 120 may be required to approve alltransactions to the bridge smart contract 28. These bridge nodes 120 mayinclude trusted entities who are responsible for the gatekeepingservice. For example, for a deposit or withdrawal from the sidechainescrow contract to be completed, a predetermined number of digitalsignatures may be required from the bridge nodes 120.

The bridge 18 may be an application, or set of applications, thatprovides the link between the side-blockchain network 12 (also referredto as a sidechain or private sidechain) and the main blockchain network24 (e.g., the Ethereum blockchain). The bridge 18 may utilize the bridgesmart contract 28 to enable communication of assets between themain-blockchain network 24 and the side-blockchain network 12. Thebridge smart contract 28 may include a bridge sidechain smart contract122 and a bridge mainchain smart contract 124. That is, the bridge 18may be responsible for sending transactions between the bridge sidechainsmart contract 122 and the bridge mainchain smart contract 124. Thebridge sidechain contract 122 may be deployed in the side-blockchainnetwork 12 and receive a transaction (e.g., a transfer of digital assets26) from the bridge 18 to deposit assets (e.g., sidechain digital tokens56) in the sidechain user wallets of players 88. The bridge mainchaincontract 124 may be deployed in the main-blockchain network 24 and allowplayers to deposit primary chain digital tokens 104 (e.g., ETH or VPP)from their primary chain wallet 34 (also referred to as a mainnetwallet) into the side-blockchain network 12.

The bridge 18 may send approvals for deposits and withdrawals using amulti-signature (multisig) wallet. A multisig wallet has a set ofpre-defined owners, and transactions must be approved with apredetermined set of signatures from owners. For example, amulti-signature wallet with five owners may require three of the fiveowners to verify a transaction before a transaction is approved to besent. For example, every owner of the multisig wallet may have a privatekey that the owners must use to sign and verify a transaction. In theabove example, three signers may be required to approve a transaction sothere is no single point of control (or failure).

For the cross-chain bridge 18, the bridge nodes 120 may be owners withrespect to the bridge 18 and each bridge node 18 may run the bridgesmart contract 28. In one embodiment, the bridge sidechain smartcontract 122 mints the funds that have been deposited and burns thefunds that will be withdrawn. The bridge mainchain smart contract 124may hold the funds that have been deposited to the side-blockchainnetwork 12 and allow the bridge nodes 120 (e.g., a set of entities withcryptographic credentials) to unlock the funds for players performingwithdrawals. Both the bridge sidechain smart contract 122 and the bridgemainchain smart contract 124 may verify the identity of the trust entity20.

In one embodiment, to initiate a deposit into the side-blockchainnetwork 12, a player may submit a transaction (e.g., an Ethereumtransaction) to the bridge mainchain smart contract 124 located on themain-blockchain network 24. For example, the bridge nodes 120 maymonitor the bridge mainchain smart contract 124 waiting for a depositevent 30 (also referred to as a deposit transaction). When a depositevent 30 is received, one bridge node 120 may read the deposit event 30and sign the deposit event 30. Another bridge node 120 may read thedeposit event 30 and also sign the deposit event 30. At this point, theminimum number of signatures may have been reached (i.e., if the minimumnumber of signatures is two) and the deposit event 30 may be sent to thebridge sidechain smart contract 122.

A similar process for withdrawal events 32 may be used with bridge nodes120 receiving a bridge sidechain smart contract 122 for a withdrawalevent 32. The bridge nodes 120 may then individually sign a bridgemainchain smart contract 124 for the withdrawal event 32. Once thebridge mainchain smart contract 124 has received at least the minimumnumber of signatures for approval, the withdrawal event 32 may beconducted. This process of bridge node 120 approval helps ensure thesecurity of both withdrawals and deposits from and to theside-blockchain network 12.

The bridge mainchain smart contract 124 may escrow all player funds. Thebridge mainchain smart contract 124 may be transparent and alltransactions to or from this contract may be viewable on themain-blockchain network 24.

In one embodiment, there is a one-to-one relationship between the assetsof the main-blockchain network 24 and the side-blockchain network 12.That is, the bridge mainchain contract 124 may hold the same number ofsidechain digital tokens 56 that are available in the side-blockchainnetwork 12. Rather than a transfer of assets 26 between theside-blockchain network 12 and the main-blockchain network 24, themain-blockchain network assets may be locked in the bridge smartcontract 28 when a deposit is made. That is, after the bridge 18 sends atransaction to the side-blockchain network 12, the primary chain digitaltoken 104 that is deposited may be locked in the bridge smart contract28 and the same amount of the sidechain digital token 56 may be mintedand sent to the player 88 in the side-blockchain network 12.

In one embodiment, the decentralized system 10 additionally includes aclient application 140 executed on the plurality of user devices 16 andin communication with the side-blockchain network 12. The clientapplication 140 executes the electronic game event 96 and provides theresult 94 of the electronic game event 96 to the table smart contract 70associated with the electronic game event 96. Before the result 94 ofthe electronic game event 96 is reported to the table smart contract 70,each player 88 involved with the electronic game event 96 may digitallysign the result 94 of the electronic game event 96.

Each player 88 may digitally sign the result of each electronic gameevent 96 (e.g., a result of a hand of poker) in any suitable manner. Forexample, each player 88 may digitally sign the result with a private key(e.g., the private key of a sidechain user wallet 36 or primary chainwallet 34).

In one embodiment, the client application 140 running on a first userdevice 16 communicates with the client application 140 running on otheruser devices 16 through a peer-to-peer (P2P) network. The clientapplication 140 may connect to the side-blockchain network 12 through anapplication programming interface (API) (e.g., the Amazon Web Services(AWS) API). The client application 140 may be based on a decentralizedarchitecture.

The nodes 14 of the side-blockchain network 12 may also execute a vaultcontract 130. The vault contract 130 may be where revenue 132 generatedon the side-blockchain network 12 is stored. For example, the vaultcontract may receive a rake (e.g., a percentage of funds associated witha result) after each electronic game event 96 (e.g., for cash games),after completion of an electronic game 95 (e.g., when a sit & go tablehas been completed), and/or as a transaction fee for a player 88withdrawing funds to the main-blockchain network 24.

The data contained in the blockchain of the side-blockchain network maybe replicated by each node that verifies new transactions and maintainsthe updated state of the blockchain of the side-blockchain network. Inthis way, the risk of data loss from the blockchain of theside-blockchain network is reduced.

Turning to FIG. 10 , a method 200 for blockchain-based token managementis shown. In step 202, the side-blockchain network 12 receives depositdata 100 from the cross-chain bridge 18 including a depositing amount ofa primary chain digital token and an identifier of at least one primarychain user wallet 114. In step 204, the side-blockchain network 12executes a bridge smart contract 28 to transfer a corresponding depositamount of a sidechain digital token to at least one of the sidechainuser wallets associated with the identified at least one primary chainuser wallet.

In step 206, the side-blockchain network 12 receives withdrawal data 110associated with a withdrawal event 32. The withdrawal data 110 includesa withdrawing amount 112 of the sidechain digital token 56 and anidentifier of at least one primary chain wallet 114. In determining step208, a check is performed by the trust entity 20 to determine whetherthe received withdrawal data 110 has been signed by the owner 42 of theidentified sidechain user wallet 36. If yes, processing moves todetermining step 210. In determining step 210, a check is performed todetermine whether the sidechain user wallet 36 is an unrestrictedwallet. If yes, processing moves to step 212. In step 212, the trustentity signs 20 the bridge smart contract 28 for the withdrawal event32.

If determining step 210 finds that the sidechain user wallet 36 is arestricted wallet, then processing moves to step 214. In step 214, thetrust entity 20 determines whether the account associated with thesidechain user wallet 36 has met specified criteria. If yes, theprocessing moves to step 212 and the trust entity 20 signs the bridgesmart contract 28 for the withdrawal event 32. If the account associatedwith the sidechain user wallet 36 has not met specified criteria in step214, then processing moves to step 216 and the trust entity 20 does notsign the bridge smart contract 28.

Following steps 212 and 216, processing moves to determining step 220.In determining step 220, a check is performed to determine whether thebridge smart contract 28 associated with the received withdrawal data110 includes at least two required signatures 38. If yes, processingmoves to step 222 and the bridge smart contract 28 is initiated totransfer a corresponding withdrawing amount of the primary chain digitaltoken 116 to the identified at least one of the primary chain wallets 34from the identified sidechain user wallet 36.

In step 226, the table factory smart contract 68 is executed to deployone or more table smart contracts 70. In step 228, the deployed tablesmart contract 70 is executed. As described above, executing the tablesmart contract 70 may join at least one player 88 by transferringdigital assets 26 from the sidechain user wallet 36 of each of the atleast one player 88 to a table wallet 86 associated with the table smartcontract 70, such that the transferred digital assets 26 stored in thetable wallet 86 are associated with the player 88. Executing the tablesmart contract 70 may also track as available funds the digital assets26 stored in the table wallet 86 for each of the players 88 includingreceiving results of an executed electronic game event 96 associatedwith the table smart contract 70. Executing the table smart contract 70may additionally remove at least one of the players 88 from the tablesmart contract 70 by transferring the available funds for the player 88from the table wallet 86 to the sidechain user wallet 36 of the player88.

In determining step 230, a check is performed to determine whether anaccount has met the specified criteria 50 and whether the time limit 54has expired. For example, if a user was given 1,000 tokens that are tobe returned unless the user player 1,000 hands of poker within 30 days,the remainder of the 1,000 tokens may be removed from the user's accountif after 30 days the user has not met the requirement of playing 1,000hands of poker. If the account has not met the specified criteria 50 andthe time limit 54 has expired, then in step 232 the identity smartcontract 62 is executed to remove the digital assets 26 from each of therestricted wallets when the account associated with the sidechain userwallet 36 has not met the specified criteria.

As described above, the nodes 14, user devices 16, bridge nodes 120, andtrust entity 20 may each be any computer device including computerprocessors 80 and non-transitory computer readable medium 82. Thecomputer processor 80 may have various implementations. For example, thecomputer processor 80 may include any suitable device, such as aprocessor (e.g., CPU), programmable circuit, integrated circuit, memoryand I/O circuits, an application specific integrated circuit,microcontroller, complex programmable logic device, other programmablecircuits, or the like. The computer processor 80 may also include anon-transitory computer readable medium, such as random-access memory(RAM), a read-only memory (ROM), an erasable programmable read-onlymemory (EPROM or Flash memory), or any other suitable medium.Instructions 84 for performing the method described below may be storedin the non-transitory computer readable medium and executed by thecomputer processor 80. The computer processor 80 may be communicativelycoupled to the computer readable medium 82 and network interface througha system bus, mother board, or using any other suitable structure knownin the art.

As will be understood by one of ordinary skill in the art, the computerreadable medium (memory) 82 may be, for example, one or more of abuffer, a flash memory, a hard drive, a removable media, a volatilememory, a non-volatile memory, a random-access memory (RAM), or othersuitable device. In a typical arrangement, the computer readable medium82 may include a non-volatile memory for long term data storage and avolatile memory that functions as system memory for the processor 82.The computer readable medium 82 may exchange data with the circuitryover a data bus. Accompanying control lines and an address bus betweenthe computer readable medium 82 and the circuitry also may be present.The computer readable medium 82 is considered a non-transitory computerreadable medium.

The instructions 84 may be any suitable computer executable instructionsfor performing the actions, steps, method, etc. described above.

All ranges and ratio limits disclosed in the specification and claimsmay be combined in any manner. Unless specifically stated otherwise,references to “a,” “an,” and/or “the” may include one or more than one,and that reference to an item in the singular may also include the itemin the plural.

Although the invention has been shown and described with respect to acertain embodiment or embodiments, equivalent alterations andmodifications will occur to others skilled in the art upon the readingand understanding of this specification and the annexed drawings. Inparticular regard to the various functions performed by the abovedescribed elements (components, assemblies, devices, compositions,etc.), the terms (including a reference to a “means”) used to describesuch elements are intended to correspond, unless otherwise indicated, toany element which performs the specified function of the describedelement (i.e., that is functionally equivalent), even though notstructurally equivalent to the disclosed structure which performs thefunction in the herein illustrated exemplary embodiment or embodimentsof the invention. In addition, while a particular feature of theinvention may have been described above with respect to only one or moreof several illustrated embodiments, such feature may be combined withone or more other features of the other embodiments, as may be desiredand advantageous for any given or particular application.

1. A computer-implemented system for electronically controlling accountsin connection with playing of an electronic game event involving playersfrom at least two classes of players including a first class of playershaving a first player attribute and a second class of players having asecond player attribute, wherein the system enables the first class ofplayers and second class of players to play against each other in aninstance of the electronic game event, and wherein the playing of thegame requires the first class of players and second class of players toeach have a first type of digital asset, the system comprising: acomputer processor and a non-transitory computer-readable storage mediumincluding executable computer instructions, which when executed by thecomputer processor cause the computer processor to perform operationsrising: maintain in the system an individual accounts for each player;store in a computer storage medium for each individual account adesignation of the account as either a restricted account or anunrestricted account based on at least whether the player is a firstclass of player or second class of player; execute computer instructionsto control access to the first type of digital asset by restrictedaccounts, including preventing purchase of the first type of digitalasset by restricted accounts but permitting the system to: i) deposit afirst quantity of the first type of digital asset in the restrictedaccount without payment from the restricted account, ii) store a firstperiod of time during which the player of a restricted account ispermitted to use the first type of digital asset to play the electronicgame event and iii) store specified criteria associated with the firstperiod of time; execute computer instructions to control access to thefirst type of digital asset by unrestricted accounts, includingpermitting the purchase of the first type of digital asset; executecomputer instructions to manage the playing of the electronic game eventincluding controlling which players are permitted to play the electronicgame event, including permitting players with restricted accounts andunrestricted accounts to play an instance of the electronic game eventagainst each other using the first type of digital asset; executecomputer instructions to receive results of the electronic game eventand, based on the results, update the amount of the first type ofdigital asset in the individual accounts of the players who play in theelectronic game event; and execute computer instructions to controlrequests by players to withdraw the first type of digital asset fromtheir accounts, including preventing a player with a restricted accountfrom withdrawing the first type of digital asset from their restrictedaccount unless the system determines the player has achieved the storedspecified criteria within the first period of time and permittingplayers with an unrestricted account to withdraw the first type ofdigital asset from their unrestricted account.
 2. The system of claim 1,wherein the processor is further configured to remove the first digitalasset from the restricted accounts at an end of the first period of timeif the player associated with the restricted account has not achievedthe specified criteria within the first period of time.
 3. (canceled) 4.(canceled)
 5. The system of claim 1, wherein the processor is furtherconfigured to reset the amount of the first type of digital asset in arestricted account at the end of the first period of time.
 6. (canceled)7. The system of claim 1 wherein: electronically updating the individualaccounts of the players of the second class comprises: receiving depositdata from a cross-chain bridge that connects a first blockchain networkcontaining a primary wallet of the second player with a secondblockchain network containing a secondary wallet of the second playerassociated with the second account, and transferring a correspondingdeposit amount of the digital asset from the primary wallet to thesecondary wallet; and electronically controlling permissions for playersto withdraw digital assets from their accounts comprises: receivingwithdrawal data, and transferring a corresponding withdrawal amount ofthe second digital asset from the secondary wallet to the primarywallet.
 8. The system of claim 1 wherein: the first player attributecomprises a limitation on the first player receiving the first digitalasset to play the electronic game event; and the second player attributecomprises a permission for the second player to purchase the seconddigital asset to play the electronic game event.
 9. (canceled) 10.(canceled)
 11. (canceled)
 12. (canceled)
 13. (canceled)
 14. (canceled)15. (canceled)
 16. (canceled)
 17. (canceled)
 18. The system of claim 1,wherein the processor is further configured to permit the second playerto associate a second wallet with the second account.
 19. The system ofclaim 1, wherein the processor is further configured to permit thesecond player to associate a second wallet with the second account anduse the second wallet to acquire the first type of digital asset. 20.(canceled)